Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/pppext/pppext-minutes-91nov.txt

Text File | 1993-02-17 | 10.3 KB | 237 lines

CURRENT_MEETING_REPORT_


Reported Brian Lloyd/Telebit

PPPEXT Minutes

Brian Lloyd welcomed the group, asked for sign-in and a short discussion
on mailing list, ppp archive availability and history of PPP Working
Group was held.  Also Brian discussed current status and current
implementations of PPP.

Bill Simpson reported that SAAG has reviewed the PPP authentication
draft document.  The result is that the message digest algorithm used in
the Challenge Handshake Authentication Protocol (CHAP) may be either MD4
or MD5.  The document is being changed to support this.  The default
algorithm will be the same as that chosen by the SNMP Working Group for
SNMP authentication.  [MD5 was chosen].

Brian Lloyd reported on the IPLDN discussion on frame relay, X.25 and
PPP over the same physical interface.  They decided to use XID to
distinguish which protocol will run on the link.

Brad Parker of Cayman gave a synopsis of the work on PPP in the
Appletalk Working Group.  Apple has chosen to use PPP instead of a
proprietary point-to-point protocol, thus paving the way for both IP and
Appletalk on the same serial interface.  The result is a document that
is ready for review by the PPP Working Group.  Two implementations are
available.  Brad has partially completed work on the drivers and [name]
at the University of Michican is planning on continuing the effort.

Phil Almquist presented the comments on the PPP requirements portion of
the Router Requirements document.  The members of the RR Working Group
objected to listing line speeds above which VJ header compression should
not be used.  The result was that the recommendation from the PPPEXT
Working Group was changed to read that VJ header compression should be
used below 20Kbps and may be used at any speed above that.  The upper
bound above which VJ header compression should not be used, previously
set at 64Kbps, was removed.

Phil also reported that there were objections by the members of the RR
Working Group to the requirement for Link Quality Monitoring (LQM). This
led into a discussion of LQM. The issue was also raised that some of the
vendors wish to do other forms of proprietary LQM.

One of the problems with the existing LQM is that it is considered to be
part of the LCP and hence must use an async control character map (ACCM)
of all 1's.  This just about doubles the size of an LQM packet on an
async link.

As a result the LCP document will be modified to support a slightly
different LQM negotiation that can support multiple types of LQM. If an
implementation supports LQM at all, it must support the existing type of
LQM so that there will be a common denominator (analogy to MIB-1 and

                                   1





MIB-2 of SNMP).

As a result of the LQM problem the group decided that all Link Control
Protocol (LCP) packet/option codes less than or equal to seven that are
needed to bring the LCP to the open state must be escaped using the
all-ones ACCM. After the link is open the other options, i.e.
authentication, new LQM, etc., may be transmitted using the negotiated
ACCM and compression options even though these packets are ostensibly
LCP packets.

There is a problem that occurs when the LCP goes to the open state and a
frame that has the ACCM set to zero (control characters not escaped)
arrives at the receiver before the receiver has updated its ACCM and
changed to the open state (this often occurs when the first NCP packet
immediately follows the last LCP ack).  The NCP frame is discarded at
the receiver.  There was a suggestion to insert a delay to allow the
receiver to get to the open state before sending the NCP packet.  It was
noted that this is not a serious problem because the standard error
recovery sequence properly deals with this.  It was decided not to make
a change in the state machine and to add an implementation note
describing the problem.

There was concern about the length of time that it can take to determine
that a link has failed (10 retries with 3 seconds between retries).  The
final decision was to make it clear that the 3 second delay may be
adjusted to accommodate links with lower latency, i.e., that high speed
link interfaces timeout values should be smaller.  This information will
be added to the LCP document and the default timeout value will become
part of the PPP MIB.

Glenn McGregor presented his IPCP document and discussed the changes to
Van Jacobson header compression as used in PPP. Now, the slot number --
which is used to identify a particular session being compressed -- is
not compressed.  This greatly improves error recovery if a packet is
lost or damaged in transit.

PPP Minutes PM Session

IP Address discussion continued.  The Working Group decided to remove
the feature for negotiating/reporting multiple IP addresses on an
interface.

In addition the Working Group decided that the IP address negotiation
procedure was too complicated to ensure that it worked properly.  The
group decided on a much simpler scheme that retains all the features of
the earlier version without the complexity.  The IPCP document will
contain a description of the old method along with a strong note
indicating that implementations should use the new IP address
negotiation procedure.  And that the old IP address negotiation will be
eliminated sometime in the not-too-distant future as the IPCP document
proceeds down the standards track.

Bill Simpson and Brian Lloyd presented the Authentication Document.  The
section on management of secrets (keys) has a hole due to the lack of

                                   2





availability of a secure mechanism for the dissemination of the
``secret''.  This will be gated by the work on Common Authentication
Technology (CAT) and on SNMP secret dissemination technology.

Also the CHAP will change the way it uses MD5 to generate the
authentication ``signature'' so as to be 100should allow the core
authentication procedures to be completely interchangable between PPP
and SNMP.

The discussion then proceeded to the call-back field of CHAP. The
purpose of this field is for one end or the other to indicate to the
peer that it wishes to terminate the link and call-back, primarily for
purposes of reversing charges (some indicated that call-back may prove
useful for enhancing security).  Several people indicated that multiple
call-back destinations may be desirable so a call-back address (phone
number) field was defined and added.

Marty Del Vecchio from Shiva Corp presented proposed Netware IPX Control
Protocol which he has implemented.  The group suggested a number of
changes and improvements.  Marty will do further research and present an
improved document soon.

Other documents were discussed.  It was noted that 3Com has implemented
stripped down versions of most of the NCPs.  There was nothing to report
on CLNP/OSI over PPP. Appletalk over PPP is very close to completion.
Michele Wright of Timplex will take over DECnet over PPP doc.  Several
of the implementors present indicated that they are actively working on
an implementation of PPP that supports DECnet.

The topic of conversation then moved on to switched circuit (dial-up,
ISDN, etc.)  connection techniques.  A discussion then ensued about
techniques for automatically starting PPP during a login process.  It
was noted that the first PPP frame on an async link consists of the
octet sequence ``7e ff 7d 03''.  This makes it possible for a terminal
server or host to recognize that the peer wishes to run PPP and may
start PPP immediately.

The discussion also went back to PPP over ISDN. The XID technique for
determining which protocol would run, e.g., PPP, frame relay, or X.25,
was discussed again.

The discussion then proceeded to the topic of inverse multiplexing,
e.g., using multiple PPP links to simulate a single link/interface with
greater bandwidth.  There is a need to add a mechanism to indicate to
the remote peer that one end or the other needs to increase capacity and
will be opening an additional link.  It was suggested that the new link
need only open the LCP and authenticate, and there is no need to
renegotiate the NCPs.  The magic number that is negotiated on a link
could be used as a logical connection number and can be made unique
across all of the logical PPP connections, e.g., all physical
connections that are part of a single logical interface will use the
same magic number.

Results and Decisions

                                   3





The group decided to move the status of the LCP document back to
``proposed'' because of the changes to LQM.

The group decided to move the status of the IPCP document back to
``proposed'' status because of the desired changes to the IP address
negotiation.

The group decided to keep the status of the Authentication document at
``proposed'' status due to the changes in the CHAP.

Attendees

Steve Alexander          [e-mail]
Fred Baker               [e-mail]
Dean Cheng               [e-mail]
Richard Cherry           [e-mail]
Curtis Cox               [e-mail]
Kenneth Crepea           [e-mail]
Marty Del Vecchio        [e-mail]
Craig Fox                [e-mail]
Chris Gunner             [e-mail]
Bob Jeckell              [e-mail]
William Jolitz           [e-mail]
Frank Kastenholz         [e-mail]
Tom Kessler              [e-mail]
Holly Knight             [e-mail]
Gordon Lee               [e-mail]
Brian Lloyd              [e-mail]
Glenn McGregor           [e-mail]
Robert Morgan            [e-mail]
Dean Morris              [e-mail]
Michael Newell           [e-mail]
Chandy Nilakantan        [e-mail]
J. Bradford Parker       [e-mail]
Miguel Sasson            [e-mail]
Mark Schaefer            [e-mail]
William Simpson          [e-mail]
Eric Smith
Ravi Srinivasan          [e-mail]
Bruce Taber              [e-mail]
Mark Therieau            [e-mail]
William Townsend         [e-mail]
Maurice Turcotte         [e-mail]
John Veizades            [e-mail]
Yuan Wang                natadm![e-mail]
Scott Wasson
Preston Wilson           [e-mail]
L. Michele Wright        uncng![e-mail]



                                   4